Tuning animation requires attention to some factors not relevant in other types of applications. This section first looks at Factors Contributing to Animation Speed, then provides some advice for Optimizing Frame Rate Performance.
The smoothness of an animation depends on its frame rate. The more frames rendered per second, the smoother the motion appears. The basic elements that contribute to the time to render a frame are shown in Table 4-1 above.
Smooth animation also requires double buffering. In double buffering, one framebuffer holds the current frame, which is scanned out to the monitor by video hardware, while the rendering hardware is drawing into a second buffer that is not visible. When the new framebuffer is ready to be displayed, the system swaps the buffers. On hardware implementations, the system must wait until the next vertical retrace period between raster scans to swap the buffers, so that each raster scan displays an entire stable frame, rather than parts of two or more frames.
Frame rates must be integral multiples of the screen refresh time, which is 16.7 msec (milliseconds) for a 60-Hz monitor. If the draw time for a frame is slightly longer than the time for n raster scans, the system waits until the n+1st vertical retrace before swapping buffers and allowing drawing to continue, so the total frame time is (n+1)*16.7 msec.
To summarize: On hardware implementations, a change in the time spent rendering a frame has no visible effect unless it changes the total time to a different integer multiple of the screen refresh time.
If you want an observable performance increase, you must reduce the rendering time enough to take a smaller number of 16.7 msec raster scans. Alternatively, if performance is acceptable, you can add work without reducing performance, as long as the rendering time does not exceed the current multiple of the raster scan time.
To help monitor timing improvements, turn off double buffering. If you don't, it's difficult to know if you're near a 16.7 msec boundary.
The most important aid for optimizing frame rate performance on hardware implementations is taking timing measurements in single-buffer mode only. (On software implementations, rendering to the front buffer may actually be slower than rendering to the back buffer. Nonetheless, it is important not to include SwapBuffers() in your timing measurement.) For more detailed information, see "Taking Timing Measurements".
In addition, follow these guidelines to optimize frame rate performance:
A program is free to do non-graphics computation during the wait cycle between vertical retraces. Therefore, issue a SwapBuffers() call immediately after sending the last graphics call for the current frame, perform computation needed for the next frame, then execute OpenGL calls for the next frame, call SwapBuffers(), and so on.
Clearing a full screen takes time. If you make additional drawing calls immediately after a screen clear, you may fill up the graphics pipeline and force the program to stall. Instead, do some non-drawing work after the clear.